System Design
picoCTF
CTFそのものはセキュリティの問題が多いが、最初の方ではシステムの知識が問われるので基礎固めにも使える
ISUCONの過去問
特定のノードにリソースを追加する
DBに有効なことが多い
ノードの数を増やす
アプリケーションに有効なことが多い
データベース
高速化のため（ただしよく考えること）
使うなら性能よりも機能に着目する
アトミックに安全に読み書きできる共有メモリ構造としてのRedis GraphDBによるグラフ操作
MongoDBのcapped collectionでメンテナンスフリーのログとして使う
どこに何が保存されているかをわかるようにしたうえで、複数のマシンに分散する
垂直分割
テーブルのうち特定のデータをマシンAへ、それ以外をマシンBへ
特定のマシンのデータが肥大化したらまた分割が必要になる
キー基準の分割（ハッシュ基準）
データのIDなどを用いて分割する
N台のマシンがあればid mod Nで割り振り先を決定する
サーバ台数を増やすと再配置が必要
ディレクトリベースの分割
検索テーブルを持つ（実質インデックス）
検索テーブルが単一障害点になり、システムの性能に支配的な影響を持つ
ポイント
様々なレイヤーで考えられる
ユーザー個別情報など可視範囲に注意する
OS
DB
メモリ
計算済のデータを格納するテーブルを用意する
アプリケーション
メモリ
起動時に読み込んでおく
Rails viewのフラグメントキャッシュ
クライアント・サーバ間
Nginxなどのリバースプロキシで対処するか、APIで対処するか
クライアント
ブラウザ
ブラウザキャッシュ
Service worker
モバイルアプリ
インアプリDB
WebViewのブラウザキャッシュ
非同期処理とキュー
実行時間がかかる処理はジョブをキューに登録し、非同期に行う
長時間処理によりアプリケーションが詰まる
ユーザー体験が悪い
Webアプリケーションにおいて複雑度は上がる
アプリケーションとジョブの間でのデータのやり取り
RailsではRedisをよく使う
受理、処理中、完了、失敗等々の考慮すべき状態が増える
終了通知
クライアントはどうやって検知するか
ネットワークメトリック
重要なメトリクスは以下
単位時間あたりに転送できるデータ量の最大値
bit/secondで表現することが多い Gb/sec etc.
単位時間あたりに実際に転送されたデータ量
ある地点から他の地点までのデータ転送にかかった時間
遅延時間を表現する
ベルトコンベアの例
ベルトを太くしてもレイテンシが変わるわけではないが、スループットとバンド幅は変わる
ベルトを短くするとレイテンシが減る。スループットは変わらない
高速なベルトコンベアにするとすべてが変わる
オンラインの場合、スループットはデータ圧縮などによりスピードアップが図れるが、レイテンシでできることはほとんどない
大量データの処理で用いられる
Map
データを受け取り、key, valueペアを生成する
Reduce
key, valueを集約して結果を生成する
その他
障害
どんな箇所でも障害は発生する可能性がある
システムが実行可能な時間の割合
信頼性
単位時間あたりのシステムの稼働率
読み込み負荷と書き込み負荷
アプリケーションの特性に依存する
read heavyならキャッシュの検討、write heavyなら非同期キューの活用を検討する
セキュリティ
テクニック
参考